An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

Hello, My app, Pulse Blocks: Block Puzzle, iOS version 1.0, was submitted on August 14, 2026 at 12:52 PM and has remained in Waiting for Review for more than 6 days. It has never moved to “In Review”. I have not received any rejection, request for additional information, or indication that action is required from my side in App Store Connect. I have also contacted Apple Developer Support, but I have not received a response yet. Could someone from App Review please confirm whether this delay is expected or whether the submission may be stuck in the review queue? I’m happy to provide any additional information privately if required. Thank you.

My app is stuck in waiting for review for the past 12 days (submitted on 9th August 2026). I am running out of timeline and would appreciate any feedback on the reason for the extended hold, do I have to do anything on my end, when do I expect the app to be reviewed. Would appreciate assistance on this. My App Apple ID: 6799715408 Any assistant will be appreciated as the project timeline is fast approaching.

My app was rejected under Guideline 2.3 (Accurate Metadata) with the standard text saying the UIRequiredDeviceCapabilities key is set up so that the app will not install on the review device. The review device was an iPad Air 11-inch (M3) on iPadOS 26.6. I inspected the Info.plist inside the exact archive that was uploaded. Everything relevant: UIRequiredDeviceCapabilities = (arm64) UIDeviceFamily = (1, 2) MinimumOSVersion = 18.0 Binary architectures = arm64 Built with Xcode 26.6, iOS 26.5 SDK An iPad Air 11-inch (M3) is arm64, is device family 2, and runs an OS far above 18.0, so as far as I can tell nothing in that plist can prevent installation. arm64 is the value Xcode injects automatically, and I have never declared the key myself. What I have already checked: There is no UIRequiredDeviceCapabilities in my source Info.plist and no INFOPLIST_KEY build setting for it. The value is injected at build time. I added the key to my own Info.plist as an empty array to try to override the injection. Xcode still writes (arm64) into the built plist, so I cannot remove it. I built the same Release configuration and installed it on an iPad Air 11-inch (M3) simulator running iPadOS 26.2, the highest iPadOS available to me. It installs and launches with no error. There are no app extensions. One target, TARGETED_DEVICE_FAMILY = "1,2". My questions: Is arm64 in UIRequiredDeviceCapabilities known to trigger this rejection on iPadOS 26 review devices, or is something else being reported under this template? Is there any supported way to suppress the value Xcode injects, or will the array always contain arm64 for an arm64-only binary? If the installation failure was real but caused by something other than this key, what else produces an install failure that App Review would attribute to UIRequiredDeviceCapabilities? Context for why I am asking here and not only in App Store Connect: the build sat in Waiting for Review for about a week and a half, I used my expedited request, it was rejected on this, I replied in Resolution Center with the plist contents and received no answer, and the resubmission is back in Waiting for Review. I am not asking anyone here to change a review outcome. I am trying to find out whether this is a known issue with the key so I can stop guessing. Any pointer would be appreciated.

Our first submission has been in Waiting for Review since August 12 — 8 days as of today. I've tried both support channels without result: Submitted a Contact Us request through App Store Connect — no reply Called Developer Support and waited on hold about an hour — no resolution The app is a straightforward iOS-only build (iPhone, no iPad). It's a first submission, not an update. Nothing in App Store Connect indicates a problem — no rejection, no metadata rejected state, no message in Resolution Center. It simply hasn't moved out of Waiting for Review. I've seen several recent threads describing the same thing, which is why I'm posting here rather than opening another ticket. Is there anything on my side that commonly causes a first submission to sit in Waiting for Review this long, or is the only option to keep waiting? Any guidance on the right escalation path would be appreciated. Thanks.

Hi everyone! I'm back again! 😄 A few months ago I posted here after submitting my first iOS app, after previously publishing it on Google Play. That experience was really helpful, so I'm hoping to get some advice from the community again. I've just submitted my new app, Vaqui, and it's currently Waiting for Review. Vaqui is an expense-sharing app for groups, mainly designed for trips. For example, three friends travel together and pay for different things: Pepe pays for the hotel. Sandra pays for groceries. Marcos pays for dinner. Everyone participates in different expenses. Vaqui calculates the resulting balances and suggests who should transfer money to whom. The app supports multiple currencies and stores the exchange rate used when an expense is recorded. The important part is that Vaqui does not process or hold money. It doesn't provide a wallet, banking account, payment processing, cards, or financial transactions. If someone owes another person money, Vaqui simply tells them something like: "Marcos owes Sandra $15,000." They make the actual transfer themselves using their bank or payment provider, outside Vaqui. The users can then mark the payment as made/received inside the app so the group knows what has already been settled. This made me wonder about something before the review starts: Would an app like Vaqui normally be considered a financial-services app by App Review, simply because it calculates debts/balances between users? Or is it generally treated as an expense-management / expense-sharing utility as long as it doesn't actually process, hold, or transfer money? I'm asking because I want to make sure I've understood the relevant App Review guidelines correctly rather than discovering during review that I've misunderstood something obvious. 😅 The current App Store Connect information is: App: Vaqui Bundle ID: mobi.todoapp.vaqui Apple ID: 6802352647 Status: Waiting for Review Platform: iOS / Flutter If anyone has submitted an app with similar functionality, I'd really appreciate hearing about your experience. Thanks! Greetings from Córdoba, Argentina 🇦🇷 And yes... once again I'm waiting for that little "In Review" notification. 🤞😂

Hello App Review team, I am requesting urgent assistance with my app review. Our previous build was approved around 5 weeks after our expected launch date, and last week we had to resubmit with a couple bugs that were fixed during the last review process. It has been 6 days since that submission, with an expedited review, and we are now 6 weeks past our launch date which has resulted in financial losses and dozens of media outlets notified weekly of delays. We would really appreciate if our latest build can be approved, as there are only minor bug fixes since the last one. Apple ID: 6748958042 Original Submission Date: 06/30/2026 Latest Submission Date: 08/14/2026 Current Status: Waiting for Review Support Case #: 20000141845140 Given the previous approval and minor changes since that build, we would greatly appreciate any escalation or update on the status of this review as we are incurring daily losses due to the review delay. Thank you!

Hello, My app submission has been waiting for review for 8 days, and there has been no status update or request for additional information. Submission ID: f9cc5319-693b-4809-8bcb-5eb0e8ad28bd I understand that review times can vary, but this is considerably longer than I have experienced before. Could an Apple representative please check whether the submission is progressing normally or if any action is required from my side? Thank you.

App: AI RunCoach — App ID 6782097197, bundle ID com.airuncoach.app, Team ID 4N3X74Y2LF When adding a new build to our External Testing group, TestFlight shows: "Before you can use TestFlight to distribute beta builds of your app, you must renew your Apple Developer Program membership." Our membership is not expired: the Membership Details page shows renewal date 20 June 2027, auto-renew ON, and the €99 fee already paid. We've also checked Agreements, Tax, and Banking — nothing shows as pending or requiring action anywhere. In the meantime, our app has been stuck in "In Review" status since August 3, and TestFlight installations also seem to be blocked. A request for an expedited review produced no result, and a request for a phone consultation did not lead to any contact either. Did anyone else experience this, and could someone advise on how to contact Apple about this? Thanks in advance for any pointers.

hi, This is my first app and I'm honestly pretty nervous about the whole review process 😅 sorry if this is a dumb question. My app got rejected for 2.1 (App Completeness), and I already replied twice in the messages under App Review, explaining our business model and giving a test account. Since then... nothing. No response. Just wondering — once I've replied there, is that enough, or do I need to do something else (like resubmit the build) to get things moving again? Kind of worried I'm missing a step somewhere. Also every single submission so far has taken way longer than the 24-48hrs Apple says. Is that normal lately, or should I be worried something's stuck on my end? Would really appreciate any advice from people who've been through this before. Thanks!

I'm getting the following error on every submission (Build 1 through 8), even after multiple clean rebuilds and manual verification of the raw manifest content: ITMS-91064: Invalid tracking information - A PrivacyInfo.xcprivacy file contains invalid tracking information at the following path: "PrivacyInfo.xcprivacy" and also "PlugIns/[WidgetName].appex/PrivacyInfo.xcprivacy" NSPrivacyTracking must be true if NSPrivacyTrackingDomains isn't empty. What I've verified locally (via plutil -p and raw cat on both the .xcarchive and the exported .ipa): Main app PrivacyInfo.xcprivacy: NSPrivacyTracking=false, NSPrivacyTrackingDomains=[] (empty) Widget PrivacyInfo.xcprivacy: same, false + empty No duplicate keys found in either file Generated an official "Privacy Report" from Xcode Organizer - no obvious conflict at the app or widget level was shown Updated GoogleMobileAds/UserMessagingPlatform SDKs to the latest version - issue persists Bundle version increments correctly with each build (confirmed via Info.plist inside the actual uploaded archive) Is there a known caching issue on the App Store Connect validation side, or something else I might be missing? Happy to share the Privacy Report PDF and archive details if helpful.

Hi everyone, Not sure if this is a known App Store Connect bug but hoping either someone here has a workaround, or an Apple engineer can help push this along. Background: this is my first In-App Purchase submission for my app. My original binary was submitted without the IAP attached (my mistake, first time doing this), so the app was rejected under Guideline 2.1(b) for referencing a paid feature whose IAP wasn't submitted for review. Since then: The IAP (non-consumable, one-time purchase) is fully configured with a review screenshot and notes, and shows status "Ready for Review" after submitting via "Add for Review" My app version is in a rejected state with an "Update Review" button available The problem: I can't get these two linked together anywhere in the UI. Clicking "Update Review" on the version page resubmits it, but never shows any option to attach the IAP Clicking "Add for Review" from the IAP page opens a Draft Submission, but that draft says "Unable to Submit for Review: To submit your items for review, add an app version for the selected platform," with no version selector anywhere in that panel Tried hard refresh, incognito, different browsers, starting a fresh draft submission. Same result every time. Result: resubmitted the app, got the exact same 2.1(b) rejection again, confirming the IAP genuinely never made it into the review package despite showing as correctly configured on my end. I've seen a few other threads describing what sounds like the exact same issue, where the "In-App Purchases and Subscriptions" section disappears from the version page after a first rejection, and the fix ended up requiring an Apple support agent to manually push the IAP status forward on the backend, without needing another binary. Has anyone found a way to trigger this from the developer side, or is direct support/engineering intervention really the only path? Already have a case open with Apple Developer Support as well, happy to share the Case ID via DM if that helps someone from Apple locate it faster. Thanks in advance for any pointers.

Our app (Apple ID 6781970154), submission a241932d, v1.0.13 (73), has been Waiting for Review since Aug 13. Timeline: rejected Aug 6 under 2.1(a) — "unable to receive verification code by email" — although our on-file review notes documented that the demo account uses a fixed verification code and requires no inbox. We replied in-thread within minutes; no response in 7 days. Resubmitted Aug 13; no response in 7 days. Support case 20000136325596 opened Aug 13; acknowledged, then silence. An expedite request was also filed. We had a Meet with App Review consultation on Aug 6 and resolved every prior issue raised. We'd be grateful for a status update in App Store Connect.

App Review Appeal Pending for More Than 10 Days — Is This Normal? Hi everyone, I’m looking for advice regarding an App Review appeal that has now been pending for more than 10 days without a decision or meaningful status update. Before submitting the appeal, our app had already been waiting for App Review for approximately 5 days. It was then reviewed and rejected, after which we submitted an appeal to the App Review Board. We understand that appeals may require additional investigation, but it has now been over 10 days since the appeal was submitted, and we still have no estimated timeline for a decision. This is significantly delaying our app release and making it difficult for us to plan updates and operations. Has anyone recently experienced a similar wait time with the App Review Board? Also, is there an official way to follow up or escalate an appeal when it has been pending for this long? We have already followed the normal appeal process and are simply trying to understand whether this timeframe is expected. Any recent experience or advice would be greatly appreciated. Thank you.

Hi, I’m looking for technical advice on a repeated App Review issue with our app, ASK VPN (Apple ID: 67...). ASK VPN is a simple consumer VPN app for iOS. It uses Apple’s Network Extension / Packet Tunnel APIs. Users sign in, retrieve their assigned VPN profile, view account status/expiry, and connect through a single main connection flow. The app was built specifically for this project. We did not purchase or reuse a VPN template or source code from another developer. I designed the product flow and UI, and used Codex AI as a development assistant. Our rejection history is: Guideline 4.3(a): Apple said the app had a similar binary, metadata, and/or concept to apps submitted by other developers, including one associated with a terminated Developer Program account. We reviewed the app, changed product-specific functionality and UI, added onboarding, privacy/VPN disclosures, localization, support features, diagnostics, and clarified the implementation to App Review. The latest rejection is now Guideline 5.6, stating that the app contains features that appear to have been intentionally hidden during review. We do not intentionally hide any functionality from App Review, and we have not been told which specific feature or behavior is considered hidden. One thing that concerns me is that the app often moves to In Review and is rejected very quickly. My main questions are: What technical factors can cause a custom-built VPN app using Network Extension / Packet Tunnel to be associated with another developer’s app or terminated account? What kinds of implementation or server-side behavior commonly lead App Review to conclude that functionality is being intentionally hidden? We are willing to provide Apple with complete source code, backend/API details, test accounts, and configuration if there is a secure review path for that. I would appreciate advice from anyone who has seen a similar 4.3(a) → 5.6 progression. Thank you.

I submitted my first public build (iOS 1.0) on July 30th for my game, Golfer's Pair-A-Dice (Apple ID: 6789222313) and it has been in "Waiting for Review" with no movement since then. I read that 24-48 hours is typical, but could take longer for first builds, but it seems like it hasn't even begun to be reviewed which is frustrating. Has anyone experienced similar wait times in the queue and had any success getting their app reviewed? I was hoping to launch on App Store and Google Play Store at same time and Google approved the app in 2 days so it has just been waiting for me to push, which I am waiting on Apple to approve so I can push both simultaneously.

Hello, My app Jewel Coloring Go! (App ID: 6785241915) appears to be stuck in the App Review process, and I would like to check whether there may be an issue with this submission. The current version was originally planned for release on July 31, 2026. However, today is Auguse 9, 2026, and the app is still in "Waiting for Review." Current status: Waiting for Review No messages in Resolution Center No requests for additional information We have also submitted multiple Support inquiries but have not received any response so far. This version is particularly important to our team, as it is tied to a planned release schedule and user acquisition activities that had already been prepared in advance. Given the unusually long delay, we are unsure whether the submission is proceeding normally or if there may be an issue requiring attention. If an Apple staff member could help check the status of this submission, it would be greatly appreciated. Thank you for your time and assistance.

Hi, re-iterating the previous post regarding the approval wait. It's now been past 48 hours since my new request for the new build, and the app still has not been approved. Would really appreciate the prompt review to avoid any further delays. Thanks in advance!

This is my first app and my first App Store submission, after a substantial amount of work preparing Rendr Markdown for release and making sure that everything was ready for Apple’s review process. I submitted Rendr Markdown 3.3.10 for macOS on August 13, 2026 at approximately 04:00 CEST. More than six days later, it is still in Waiting for Review. As a new Apple developer, I have to admit that I am surprised by this experience, particularly by the lack of any indication of what is causing the delay or when the submission might be reviewed. I previously spoke with Apple Developer Support regarding another App Store Connect matter. During that call, the representative also checked the app submission and confirmed that it appeared to be correctly submitted and in the review queue. As the delay continued, I contacted App Review through the App Review Status support form. I have not received a response or any indication that the case is being investigated. There have been no status changes, review messages, rejections, or requests for additional information. I therefore do not know whether this is simply an unusually long review queue or whether the submission requires intervention from Apple. Could someone from App Review please check whether this submission is progressing normally, or escalate the existing support case if necessary? App: Rendr Markdown Platform: macOS Version: 3.3.10 Apple ID: 6799048174 Submission ID: 020fe5c8-7db6-4432-969f-bb0a49d1efdc Support case: 20000140663217 Thank you.

Hello Apple Developer Community and App Review Team, I received a Pending Termination Notice on May 29, 2026, for my account (Developer: Bushra Malik) related to Section 3.2(f), regarding app submissions for Dress Up Fashion: Styling Game. I submitted a formal appeal 10 days ago but have not yet received a response or case number confirmation. I want to provide brief context: Our original Clothing Store Simulator received repeated rejections. Rather than continuing to resubmit the same app, we made the decision to build a completely new game from scratch — new code, new assets, new UI, and a fully revised App Store listing. Nothing from the original submission was carried forward. This was a deliberate good faith effort to achieve compliance, not an attempt to evade review. We also believe an older binary may have been reviewed rather than our latest build — a technical issue we have experienced previously on this account. Our account has 4+ years of publishing history and 25+ live games currently on the App Store. Not a single other app is in rejection or under any violation. We have never engaged in subscription scams, fake reviews, bait-and-switch tactics, or any of the fraudulent conduct described in the termination notice. I am respectfully requesting: Confirmation that my appeal is actively under review A status update or case reference number Any additional information Apple needs from our side We are fully cooperative and have all source code, assets, and submission history available immediately upon request. Thank you sincerely for your time. Bushra Malik Apple Developer Account: Bushra Malik